1
2
Nästa
Nej.
JSON är endast data, och om du inkluderar en kommentar kommer det också att vara data.
Du kan ha ett utsett dataelement som heter "_comment" (eller något) som ska ignoreras av appar som använder JSON-data.
Du skulle förmodligen vara bättre med kommentaren i de processer som genererar / tar emot JSON, eftersom de ska veta vad JSON-data kommer att vara i förväg, eller åtminstone strukturen för den.
Men om du bestämde dig för att:
{
"_comment": "kommentartexten går här ...",
"ordlista": {
"title": "exempel ordlista",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Ett metamarkeringsspråk, som används för att skapa markeringsspråk som DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markering"
}
}
}
}
}
|
Nej, kommentarer i formuläret // ... eller / * ... * / är inte tillåtna i JSON. Detta svar är baserat på:
https://www.json.org
RFC 4627:
Applikationen / json Media Type for JavaScript Object Notation (JSON)
RFC 8259 JavaScript Object Notation (JSON) Data Interchange Format (super Mercedes RFCs 4627, 7158, 7159)
|
Inkludera kommentarer om du väljer; ta bort dem med en minifier innan de analyseras eller sänds.
Jag släppte precis JSON.minify () som tar bort kommentarer och blanksteg från ett block av JSON och gör det giltigt JSON som kan analyseras. Så du kan använda det som:
JSON.parse (JSON.minify (my_str));
När jag släppte den fick jag en enorm motreaktion av människor som inte instämde med ens tanken på det, så jag bestämde mig för att jag skulle skriva ett omfattande blogginlägg om varför kommentarer är vettiga i JSON. Den inkluderar denna anmärkningsvärda kommentar från skaparen av JSON:
Antag att du använder JSON för att behålla konfigurationsfiler, som du vill kommentera. Fortsätt och sätt in alla kommentarer du gillar. Rör sedan genom JSMin innan du lämnar den till din JSON-parser. - Douglas Crockford, 2012
Förhoppningsvis är det till hjälp för dem som inte håller med om varför JSON.minify () kan vara användbart.
|
Kommentarer togs bort från JSON genom design.
Jag tog bort kommentarer från JSON eftersom jag såg att folk använde dem för att hålla analysdirektiv, en metod som skulle ha förstört interoperabilitet. Jag vet att bristen på kommentarer gör vissa människor ledsna, men det borde det inte.
Antag att du använder JSON för att behålla konfigurationsfiler, som du vill kommentera. Fortsätt och sätt in alla kommentarer du gillar. Rör sedan genom JSMin innan du lämnar den till din JSON-parser.
Källa: Offentligt uttalande av Douglas Crockford om G +
|
JSON stöder inte kommentarer. Det var heller inte avsett att användas för konfigurationsfiler där kommentarer skulle behövas.
Hjson är ett konfigurationsfilformat för människor. Avslappnad syntax, färre misstag, fler kommentarer.
Se hjson.github.io för JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ och C # bibliotek.
|
ANSVARSFRISKRIVNING: DIN GARANTI GÅR INTE
Som påpekats utnyttjar detta hack implementeringen av specifikationen. Inte alla JSON-analysatorer förstår denna typ av JSON. Speciellt strömmande parsers kommer att kvävas.
Det är en intressant nyfikenhet, men du borde verkligen inte använda den för någonting alls. Nedan är det ursprungliga svaret.
Jag har hittat ett litet hack som låter dig placera kommentarer i en JSON-fil som inte påverkar tolkningen eller ändrar data som representeras på något sätt.
Det verkar som om du förklarar ett objekt bokstavligt kan du ange två värden med samma nyckel, och det sista har företräde. Tro det eller inte, det visar sig att JSON-analysatorer fungerar på samma sätt. Så vi kan använda detta för att skapa kommentarer i källan JSON som inte kommer att finnas i en analyserad objektrepresentation.
({a: 1, a: 2});
// => Objekt {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Längd;
// => 1
Om vi använder den här tekniken kan din kommenterade JSON-fil se ut så här:
{
"api_host": "Värdnamnet på din API-server. Du kan också ange porten.",
"api_host": "hodorhodor.com",
"retry_interval": "Intervallet i sekunder mellan att försöka misslyckade API-samtal",
"försök_intervall": 10,
"auth_token": "Autentiseringstoken. Den finns i din utvecklarpanel under" Inställningar "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "En matris som innehåller mina favoritnummer hela tiden",
"favoritnummer": [19, 13, 53]
}
Ovanstående kod är giltig JSON. Om du analyserar det får du ett sådant objekt:
{
"api_host": "hodorhodor.com",
"försök_intervall": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favoritnummer": [19,13,53]
}
Vilket innebär att det inte finns några spår av kommentarerna, och de kommer inte att ha konstiga biverkningar.
Lycklig hacking!
|
Överväg att använda YAML. Det är nästan ett superset av JSON (praktiskt taget alla giltiga JSON är giltiga YAML) och det tillåter kommentarer.
|
Du kan inte. Det är åtminstone min erfarenhet från en snabb blick på json.org.
JSON har sin syntaxvisualiseras på den sidan. Det finns ingen anteckning om kommentarer.
|
Kommentarer är inte en officiell standard, även om vissa parsers stöder C ++ - stil kommentarer. En som jag använder är JsonCpp. I exemplen finns den här:
// Konfigurationsalternativ
{
// Standardkodning för text
"kodning": "UTF-8",
// Plugin-program laddade vid start
"plug-ins": [
"pytonorm",
"c ++",
"rubin"
],
// Storlek för flikindrag
"indent": {"length": 3, "use_space": true}
}
jsonlint validerar inte detta. Så kommentarer är en parserspecifik förlängning och inte standard.
En annan analysator är JSON5.
Ett alternativ till JSON TOML.
Ett ytterligare alternativ är jsonc.
Den senaste versionen av nlohmann / json har valfritt stöd för att ignorera kommentarer vid tolkning.
|
Du bör skriva ett JSON-schema istället. JSON-schemat är för närvarande en föreslagen specifikation för internetutkast. Förutom dokumentation kan schemat också användas för att validera dina JSON-data.
Exempel:
{
"description": "En person",
"typ": "objekt",
"egenskaper":
{
"namn":
{
"type": "string"
},
"ålder":
{
"type": "heltal",
"maximalt": 125
}
}
}
Du kan tillhandahålla dokumentation med hjälp av attributet beskrivningsschema.
|
Om du använder Jackson som din JSON-parser, så gör du det för att tillåta kommentarer:
ObjectMapper mapper = ny ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Då kan du ha kommentarer så här:
{
nyckel: "värde" // Kommentar
}
Och du kan också ha kommentarer som börjar med # genom att ställa in:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Men i allmänhet (som svarat tidigare) tillåter specifikationen inte kommentarer.
|
Här är vad jag hittade i Google Firebase-dokumentationen som låter dig lägga kommentarer i JSON:
{
"//": "Vissa webbläsare använder detta för att aktivera push-aviseringar.",
"//": "Det är detsamma för alla projekt, detta är inte ditt projekts avsändar-ID",
"gcm_sender_id": "1234567890"
}
|
NEJ. JSON brukade stödja kommentarer, men de missbrukades och togs bort från standarden.
Från skaparen av JSON:
Jag tog bort kommentarer från JSON eftersom jag såg att folk använde dem för att hålla analysdirektiv, en metod som skulle ha förstört interoperabilitet. Jag vet att bristen på kommentarer gör vissa människor ledsna, men det borde det inte. - Douglas Crockford, 2012
Den officiella JSON-webbplatsen finns på JSON.org. JSON definieras som en standard av ECMA International. Det finns alltid en framställningsprocess för att få standarder reviderade. Det är osannolikt att anteckningar kommer att läggas till JSON-standarden av flera skäl.
JSON by design är ett lätt omvandlat (mänskligt analyserat) alternativ till XML. Det är förenklat till och med så att kommentarer inte är onödiga. Det är inte ens ett markeringsspråk. Målet är stabilitet och interoperabilitet.
Den som förstår "has-a" -förhållandet mellan objektorientering kan förstå vilken JSON-struktur som helst - det är hela poängen. Det är bara en riktad acyklisk graf (DAG) med nodtaggar (nyckel / värdepar), vilket är en nästan universell datastruktur.
Den enda anteckningen som krävs kan vara "// Dessa är DAG-taggar". Nyckelnamnen kan vara så informativa som krävs, vilket möjliggör godtycklig semantisk aritet.
Varje plattform kan analysera JSON med bara några kodrader. XML kräver komplexa OO-bibliotek som inte är genomförbara på många plattformar.
Annoteringar skulle bara göra JSON mindre interoperabelt. Det finns helt enkelt inget annat att lägga till, såvida inte det du verkligen behöver vara ett markeringsspråk (XML), och bryr dig inte om dina bestående data lätt kan analyseras.
MEN som skaparen av JSON också observerade, har det alltid funnits JS-pipelinstöd för kommentarer:
Fortsätt och sätt in alla kommentarer du gillar.
Rör sedan genom JSMin innan du lämnar den till din JSON-parser. - Douglas Crockford, 2012
|
Om din textfil, som är en JSON-sträng, kommer att läsas av något program, hur svårt skulle det vara att ta bort antingen C- eller C ++ -stil innan du använder den?
Svar: Det skulle vara ett liner. Om du gör det kan JSON-filer användas som konfigurationsfiler.
|
Om du använder Newtonsoft.Json-biblioteket med ASP.NET för att läsa / deserialisera kan du använda kommentarer i JSON-innehållet:
// "name": "string"
// "id": int
eller
/* Det här är en
kommentar exempel * /
PS: Kommentarer med en rad stöds endast med 6+ versioner av Newtonsoft Json.
Ytterligare anmärkning för personer som inte kan tänka ut ur rutan: Jag använder JSON-formatet för grundläggande inställningar i en ASP.NET-webbapplikation som jag gjorde. Jag läser filen, konverterar den till inställningsobjektet med Newtonsoft-biblioteket och använder den vid behov.
Jag föredrar att skriva kommentarer om varje enskild inställning i själva JSON-filen och jag bryr mig verkligen inte om integriteten för JSON-formatet så länge det bibliotek jag använder är OK med det.
Jag tror att det här är ett "lättare att använda / förstå" sätt än att skapa en separat "settings.README" -fil och förklara inställningarna i den.
Om du har problem med denna typ av användning; förlåt, genien är ur lampan. Folk skulle hitta andra användningsområden förJSON-format, och det finns inget du kan göra åt det.
|
Tanken bakom JSON är att tillhandahålla enkelt datautbyte mellan applikationer. Dessa är vanligtvis webbaserade och språket är JavaScript.
Det tillåter inte riktigt kommentarer som sådan, men att skicka en kommentar som ett av namnet / värdeparen i data skulle verkligen fungera, även om den informationen uppenbarligen skulle behöva ignoreras eller hanteras specifikt av tolkningskoden.
Allt som sagt, det är inte avsikten att JSON-filen ska innehålla kommentarer i traditionell mening. Det borde bara vara data.
Ta en titt på JSONs webbplats för mer information.
|
JSON stöder inte kommentarer inbyggt, men du kan skapa din egen avkodare eller åtminstone förprocessor för att ta bort kommentarer, det är helt bra (så länge du bara ignorerar kommentarer och inte använder dem för att vägleda hur din applikation ska behandla JSON-data ).
JSON har inga kommentarer. En JSON-kodare FÅR INTE skriva ut kommentarer.
En JSON-avkodare KAN acceptera och ignorera kommentarer.
Kommentarer ska aldrig användas för att överföra något meningsfullt. Det är
vad JSON är för.
Jfr: Douglas Crockford, författare till JSON spec.
|
Jag har just stött på detta för konfigurationsfiler. Jag vill inte använda XML (ordentligt, grafiskt, ful, svårläst) eller "ini" -format (ingen hierarki, ingen riktig standard, etc.) eller Java "Properties" -format (som .ini).
JSON kan göra allt de kan göra, men det är mycket mindre ordentligt och mer läsbart för människor - och analysatorer är enkla och allmänt förekommande på många språk. Det är bara ett träd av data. Men kommentarer utanför bandet är ofta en nödvändighet för att dokumentera "standard" -konfigurationer och liknande. Konfigurationer ska aldrig vara "fullständiga dokument", utan träd med sparade data som kan vara läsbara för människor när det behövs.
Jag antar att man kan använda "#": "kommentar" för "giltig" JSON.
|
Det beror på ditt JSON-bibliotek. Json.NET stöder JavaScript-stil kommentarer, / * kommission * /.
Se en annan Stack Overflow-fråga.
|
JSON är mycket meningsfullt för konfigurationsfiler och annan lokal användning eftersom det är allestädes närvarande och för att det är mycket enklare än XML.
Om människor har starka skäl mot att ha kommentarer i JSON när de kommunicerar data (oavsett om de är giltiga eller inte), kan JSON eventuellt delas i två:
JSON-COM: JSON på kabeln, eller regler som gäller när du kommunicerar JSON-data.
JSON-DOC: JSON-dokument eller JSON i filer eller lokalt. Regler som definierar ett giltigt JSON-dokument.
JSON-DOC tillåter kommentarer, och andra mindre skillnader kan existera som att hantera blanksteg. Parsers kan enkelt konvertera från en specifikation till en annan.
När det gäller anmärkningen från Douglas Crockford om dessa frågor (refererad av @Artur Czajka)
Antag att du använder JSON för att behålla konfigurationsfiler, som du vill kommentera. Fortsätt och sätt in alla kommentarer du gillar. Rör sedan genom JSMin innan du lämnar den till din JSON-parser.
Vi pratar om en generisk konfigurationsfilproblem (tvärspråk / plattform), och han svarar med ett JS-specifikt verktyg!
Visst att en JSON-specifik minify kan implementeras på vilket språk som helst,
men standardisera detta så att det blir allmänt förekommande över parsers på alla språk och plattformar så att folk slutar slösa bort sin tid och saknar funktionen eftersom de har bra användningsfall för det, letar upp frågan i onlineforum och får folk att berätta att det är en dålig idé eller föreslår att det är lätt att implementera borttagning av kommentarer från textfiler.
Den andra frågan är interoperabilitet. Anta att du har ett bibliotek eller API eller någon form av delsystem som har några konfigurations- eller datafiler associerade. Och det här delsystemet är
för åtkomst från olika språk. Sedan går du vidare och berättar för folk: förresten
glöm inte att ta bort kommentarerna från JSON-filerna innan du skickar dem till tolkaren!
|
Om du använder JSON5 kan du inkludera kommentarer.
JSON5 är ett föreslaget tillägg till JSON som syftar till att göra det lättare för människor att skriva och underhålla för hand. Det gör detta genom att lägga till några minimala syntaxfunktioner direkt från ECMAScript 5.
|
JavaScript-verktygslådan Dojo Toolkit (åtminstone från version 1.4) låter dig inkludera kommentarer i din JSON. Kommentarerna kan vara av / * * / format. Dojo Toolkit förbrukar JSON via dojo.xhrGet () -samtalet.
Andra JavaScript-verktygslådor kan fungera på samma sätt.
Detta kan vara till hjälp när du experimenterar med alternativa datastrukturer (eller till och med datalistor) innan du väljer ett slutgiltigt alternativ.
|
JSON är inte ett inramat protokoll. Det är ett språkfritt format. Så en kommentars format definieras inte för JSON.
Som många har föreslagit finns det några knep, till exempel dubblettangenter eller en specifik tangent _kommentar som du kan använda. Det är upp till dig.
|
Du kan ha kommentarer i JSONP, men inte i ren JSON. Jag har just spenderat en timme på att få mitt program att fungera med detta exempel från Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Om du följer länken kommer du att se
? (/ * AAPLhistorisk OHLC-data från Google Finance API * /
[
/ * Maj 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Eftersom jag hade en liknande fil i min lokala mapp fanns det inga problem med samma ursprungspolicy, så jag bestämde mig för att använda ren JSON ... och naturligtvis misslyckades $ .getJSON tyst på grund av kommentarerna.
Så småningom skickade jag bara en manuell HTTP-begäran till adressen ovan och insåg att innehållstypen var text / javascript eftersom JSONP returnerar rent JavaScript. I detta fall är kommentarer tillåtna. Men min applikation returnerade innehållstypsapplikation / json, så jag var tvungen att ta bort kommentarerna.
|
Det här är en "kan du" -fråga. Och här är ett "ja" svar.
Nej, du bör inte använda duplicerande objektmedlemmar för att fylla sidakanaldata i en JSON-kodning. (Se "Namnen i ett objekt BÖR vara unika" i RFC).
Och ja, du kan infoga kommentarer runt JSON, som du kan analysera.
Men om du vill ha ett sätt att infoga och extrahera godtycklig sidakanaldata till en giltig JSON, här är ett svar. Vi utnyttjar den icke-unika representationen av data i en JSON-kodning. Detta är tillåtet * i avsnitt två i RFC under "mellanslag tillåts före eller efter någon av de sex strukturella tecknen".
* RFC anger endast "mellanslag är tillåtet före eller efter någon av de sex strukturella tecknen", utan att uttryckligen nämna strängar, siffror, "falska", "sanna" och "null". Denna utelämning ignoreras i ALLA implementeringar.
Först kanoniserar du din JSON genom att minifiera den:
$ jsonMin = json_encode (json_decode ($ json));
Koda sedan din kommentar i binär:
$ hex = packa upp ('H *', $ kommentar);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Steg sedan din binär:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Här är din produktion:
$ jsonWithComment = $ steg. $ jsonMin;
|
Ansvarsfriskrivning: Det här är dumt
Det finns faktiskt ett sätt att lägga till kommentarer och hålla sig inom specifikationen (ingen ytterligare parser behövs). Det kommer dock inte att resultera i mänskliga läsbara kommentarer utan någon form av tolkning.
Du kan missbruka följande:
Obetydligt utrymme är tillåtet före eller efter någon symbol.
Vitt utrymme är vilken sekvens som helst av en eller flera av följande koder
poäng: teckentabell (U + 0009), linjematning (U + 000A), transport
retur (U + 000D) och mellanslag (U + 0020).
På ett hackigt sätt kan du missbruka detta för att lägga till en kommentar. Till exempel: starta och avsluta din kommentar med en flik. Koda kommentaren i base3 och använd de andra blankstegstecknen för att representera dem. Till exempel.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hej bas tre i ASCII) Men istället för 0 använd utrymme, för 1 använd radmatning och för 2 använd vagnretur.
Detta kommer bara att lämna dig med en hel del oläsligt tomt utrymme (såvida du inte skapar ett IDE-plugin för att koda / avkoda det direkt)
Jag har aldrig ens försökt detta, av uppenbara skäl och det borde du inte heller.
|
JSON tillåter inte kommentarer i sig. Resonemanget är helt dumt, eftersom du kan använda JSON själv för att skapa kommentarer, vilket helt undviker resonemanget och laddar tolkningsutrymmet utan goda skäl alls för exakt samma resultat och potentiella problem, som de är: en JSON fil med kommentarer.
Om du försöker lägga in kommentarer (med // eller / * * / eller # till exempel), misslyckas vissa parsers eftersom detta strikt inte är
inom JSON-specifikationen. Så du borde aldrig göra det.
Här, till exempel, där mitt bildmanipuleringssystem har sparat bildnoteringar och lite grundläggande formaterad (kommentar) information om dem (längst ner):
{
"Noteringar": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"utsträckningX": 356,
"utsträckning": 294,
"opacitet": 0,5,
"text": "Elliptiskt område ovanpå",
"textX": 333,
"textY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rektangel",
"measureX": 109,
"utsträckning": 412,
"opacitet": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"utsträckningX": 102,
"utsträckning": 136,
"opacitet": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Enkel polygon",
"textX": 85,
"textY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON-bildnotationsdata:",
"c02": "-------------------------",
"c03": "",
"c04": "Dessa data innehåller bildnoteringar och relaterat område",
"c05": "urvalsinformation som ger ett medel för en",
"c06": "bildgalleri för att visa noteringar med elliptisk,",
"c07": "indikationer på rektangulär, polygonal eller frihand",
"c08": "över en bild som visas för en galleribesökare.",
"c09": "",
"c10": "X- och Y-positionerna är alla i bildenPlats. Bilden",
"c11": "upplösning ges som imageXW och imageYW, vilken",
"c12": "du använder för att skala skalningsområdena till deras rätta",
"c13": "platser och storlekar för din bildvisning,",
"c14": "oavsett skala.",
"c15": "",
"c16": "För ellipser är ankaret centrum för ellipsen,",
"c17": "och omfattningen är X- och Y-radierna.",
"c18": "",
"c19": "För rektanglar är ankaret längst upp till vänster och",
"c20": "extents längst ner till höger.",
"c21": "",
"c22": "För frihands- och polygonområdeslägen, pointList",
"c23": "innehåller en serie med numrerade XY-punkter. Om området",
"c24": "är stängd, den sista punkten kommer att vara densamma som",
"c25": "först, så allt du behöver tänka på är att rita",
"c26": "linjer mellan punkterna i listan. Ankare och omfattning",
"c27": "är inställda längst upp till vänster och längst ner till höger om den angivna",
"c28": "region, och kan användas som en enkel rektangulär",
"c29": "upptäcka för musens position över dessa typer",
"c30": "av områden.",
"c31": "",
"c32": "Positionerna textx och texty ger grundläggande positionering",
"c33": "information som hjälper dig att hitta textinformationen",
"c34": "på ett rimligt läge associerat med området",
"c35": "indikation.",
"c36": "",
"c37": "Opacitet är ett värde mellan 0 och 1, där .5 representerar",
"c38": "en 50% ogenomskinlig bakgrund och 1.0 representerar en helt ogenomskinlig",
"c39": "bakgrund. Rekommendation är att regioner dras",
"c40": "endast om användaren svänger pekaren över bilden,",
"c41": "och att texten som hör till regionerna dras",
"c42": "endast om användaren svänger pekaren över det angivna",
"c43": "region."
}
}
|
Vi använder strip-json-kommentarer för vårt projekt. Den stöder något som:
/ *
* Beskrivning
* /
{
// regnbågar
"enhörning": / * ❤ * / "tårta"
}
Helt enkelt npm installera - spara strip-json-comments för att installera och använda det som:
var strip_json_comments = kräver ('strip-json-comments')
var json = '{/ * rainbows * / "unicorn": "cake"}';
JSON.parse (strip_json_comments (json));
// => {unicorn: 'cake'}
|
I mitt fall måste jag använda kommentarer för felsökningsändamål precis innan utdata från JSON-strukturen. Så jag bestämde mig för att använda felsökningsinformation i HTTP-rubriken för att undvika att bryta klienten:
header ("My-Json-Comment: Ja, jag vet att det är en lösning ;-)");
|
För att skära ett JSON-objekt i delar lägger jag till "dummy comment" -rader:
{
"#############################" : "Del 1",
"data1": "värde1",
"data2": "värde2",
"#############################" : "Del 2",
"data4": "värde3",
"data3": "värde4"
}
|
1
2
Nästa
Mycket aktiv fråga. Tjäna 10 rykte för att svara på den här frågan. Kravet på rykte hjälper till att skydda denna fråga från skräppost och icke-svar-aktivitet.
Inte svaret du letar efter? Bläddra bland andra frågor taggade JSON-kommentarer eller ställ din egen fråga.